Since the beginning of electronic computing, there has been a never-ending concern that the hardware and/or software comprising the computers—to say nothing of user and other data—has been deliberately or inadvertently corrupted. As the complexity of computers increases, so does this concern. At the heart of the problem is trust, or the lack thereof. Software, hypervisors (in virtualized computer systems), operating systems (OS) and applications and the like that run on modern computers, servers, mobile devices, etc., assume, for example, that the hardware on which they are running can be trusted—when software stores information in memory, it expects the information to be the same the next time it is read from memory and not tampered with or leaked to an attacker.
With an increase of platform modularization, it is possible for a human operator or a hardware component to modify the state of the software out-of-band of its execution. For example, every device that is connected to main memory through an I/O bus (for example, a PCI bus) can communicate with the software by means of writing and reading not only to shared areas but also from the application private state that is stored in the main memory. For these and many other reasons, the problem of trust is more prevalent today than ever before, especially as more and more organizations rely on service providers or manufacturers to run their software and build the systems on which they run.
An attacker can successfully penetrate a software system just by observing, without modifying, the state of the application. One example of such an attack consists of just observing data stored in memory (for example, credit card numbers, personally identifying information, etc.) without requiring access credentials such as passwords. Another example is known as a “cold-boot” attack, which exploits the physical property of system memory (in particular, DRAM) that its contents are retained for a short time even when the power is removed. In such attacks, a human can force a reboot of the system, often just by causing a loss of power or reset, and then, while data is still latent, reboot into a small (even USB-based) OS that then can observe or copy the data from the supposedly secure hardware; alternatively, the user can quickly remove the main memory device from one host and mount it on another host in order to read its content. The cold-boot attack is explained, for example, in http://citp.princeton.edu/memory/. By observing the state of the software, that is, the contents of memory, the attacker can then obtain secrets and credentials (for example, keys) that later allow the attacker entry through the front door of the software stack.
Consequently, a whole branch of computer science is dedicated to finding solutions to the problem of trust. Some of the concepts and attempted solutions include the following.
“Data-at-rest” encryption involves encrypting data at the storage back-end, that is, data that is not, at a given moment, being transmitted between devices or otherwise processed. Although this method provides a relative easy and straightforward way to encrypt substantially the entire non-volatile storage, it does not protect data that is currently being processed or used. Yet another drawback is that any keys used to encrypt the “at-rest” data must be stored and persist as long as the data; keys themselves are subject to theft while in memory, which would defeat the encryption as a whole.
“Cryptoprocessors” have been in use since the early days of computers. In broad terms, a conventional, modern cryptoprocessor is some form of microprocessor (including smartcards) that includes built-in hardware support for cryptographic operations. In short, existing cryptoprocessor-based security solutions rely on dedicated or specialized hardware and typically also on modifications to the processor circuitry itself. One variant of this concept is “in-line processor RAM encryption”, which is a hardware-based approach to the problem in which the CPU integrates encryption logic into the cache circuitry, and which enables encryption/decryption whenever cache data is either evicted or filled. Although commodity operating systems can run on some known cryptoprocessors, at present there is no cryptoprocessor implementation, in the sense of full-memory encryption, for an x86 architecture.
The Trusted Computing Group TCG (http://www.trustedcomputinggroup.org) works on a solution that can attest to the software that has started to execute on a processor after a system boot, or in the case of Intel's TXT (Trusted Execution Technology) (http://download.Intel.com/technology/security/downloads/315168.pdf), whenever a software component decides to execute in a measured environment. Once the system has started to run the measured code, however, the TCG framework no longer provides additional run-time protection.
“Messaging encryption” is a system concept for secure communication (for example, VPN, IPsec, SSL) that allows hosts or other software entities to communicate privately over public networks. Note that this is a form of encryption for “data-in-motion”. Although this method provides a level of security for data in transit between two entities, it is not designed or suitable for protecting data being otherwise processed before or after transit.
Various researchers have started to experiment with using private storage in the CPU to hide data, in particular the x86 internal state, from the main memory. One such example is TRESOR (http://www.usenix.org/events/sec11/tech/full_papers/muller.pdf), which contains references to “frozen cache”. Research in this area has demonstrated the ability to protect some data from reaching RAM, but not the entire software stack. This solution therefore has the weakness that an attacker can easily modify other data that is exposed to the RAM and modify its software component to expose all secrets.
“Cache management via page coloring” (http://en.Wikipedia.org/wiki/cache_coloring) is a method to split the cache content between multiple applications running on a single x86 processor. This method divides the total set of physical pages into pages that are “known” not to conflict “as far as cache placement is concerned”, assuming that if each application allocates only from one pool of pages having color A, it will never contend with another application that allocates from another pool of pages having color B. In this way, the application using color A cannot cause evictions of cached data associated with application using color B, and vice versa, but it does not provide any guarantee as to which pages in a given pool are currently in the cache or in system memory.